Generally, a pipeline system provides a continuous pipe conduit along with a variety of related components and equipment, e.g., valves, compressor stations, communications systems, and meters, etc. Pipelines are frequently used to transport liquid or gaseous materials from one point to another, usually from a point (or points) of production or processing to another or to points of use. For example, an air separation unit may be used at a production facility to separate atmospheric air into gaseous components (e.g., oxygen gas (O2) nitrogen gas (N2), Argon gas (Ar), etc.). The resulting materials may be transported through the pipeline. At compressor stations, compressors maintain the pressure of the material in the pipeline as it is transported from one site to another. Similarly, for a liquid bearing pipeline, pumps may be used to introduce and maintain pressure of a liquid substance transported by the pipeline.
Obviously, running and maintaining a pipeline system can be expensive and complex. The operations of a pipeline system are frequently coordinated and controlled from a central operations control center. At such a control center, an operator may monitor the operational state of the pipeline and each of its constituent elements. To perform this task, software applications are available that monitor the operational state of pipeline components, including compressors and pumps, valves, segments, etc. Sensors affixed to these (and other) field devices are configured to relay information regarding a then current state of the device to the control center. A real-time status database is used to capture this information and make it available to the relevant individuals at the control center. In some cases, the monitoring systems may be configured to raise an alarm when a monitored parameter (or combination of parameters) falls below (or climbs above) a predetermined value.
Other complex industrial systems and processes use a similar approach. For example, a petroleum refinery (at one end of a pipeline) may be monitored from a central control center using a real-time status database configured to receive data collected from the field devices of the refinery. Fleet management applications used to monitor the location and status of a fleet of delivery vehicles provide another example of a large complex operation that may be monitored from a central control center using a real-time status database.
For these systems, a central concern is the ongoing operational state of the system at any given point in time, and the real-time status database is an effective tool for monitoring this. Frequently however, system operators need access to not just the current status available from the real-time database, but also to historical data regarding the operational state of the system. Accordingly, the control center for a pipeline (or other industrial system) may include a “historian database,” or more simply, a “historian.” A historian is used to archive values from the real-time status database for the monitored field devices. That is, while the real-time status database may record the current pressure at a given pipeline location, the historian may store what the same value was a minute, hour, day week, or even years ago. The historian may be queried for historical values by the relevant individuals at the control center. Such information may be needed for a variety of purposes, including, for example, optimizing system operations, understanding the impact of changes over time, ensuring regulatory compliance, and many other applications. Thus, the historian database often becomes a critical component for ongoing operations of a pipeline (or other industrial system).
Ideally, whenever any value in the real-time database changes, the previous value should be archived by the historian. Additionally, some values may need to be archived at regular intervals, regardless of whether the value has changed. If the historian should fail, for any reason, this information may be lost. Because of the importance of this historical data, pipeline (or other industrial system) operators may use a second historian to provide redundancy in case of failure. Should a primary historian go down, a secondary (or back-up) historian may take over archiving values from the real-time status database. By using a redundant back-up, a system operator avoids losing valuable archival data when a primary historian goes down.
Eventually, a failed historian system may be brought back on line. Problems arise, however, as the primary and secondary historian systems are, essentially, meant to be duplicates of one another. When one historian is brought back on-line, it needs to be synchronized with the other system. One approach to synchronizing the historian systems is to replicate the complete historical archive from the historian system that did not fail to the one that did. Given the scope of many industrial operations, the volume of data to replicate may simply make such an approach impractical, at best. For example, pipeline systems are frequently large and complex with hundreds, if not thousands, of monitored field devices, and thousands, if not tens-of-thousands, of monitored parameters, and potentially terabytes of data. Other large industrial operations are often just as complex.
Further, the synchronization process may need to go both ways between the primary and the secondary historians. For example, a system problem may result in intermittent outages where both the primary and the secondary go down at different times. In such a case, the primary and the secondary historian may both have archival data that needs to be synchronized with the other. In such cases, the simple replication approach is inadequate.
As the foregoing discussion demonstrates, providing a fault-tolerant historian is a difficult task for operators of a complex industrial operation such as a pipeline. Accordingly, there remains a need in the art for techniques for synchronizing a primary and a secondary historian system used to archive values from a real-time status database.